a t e v a n s . c o m

So, I'm playing with Flixel, which is making Flash games actually fun to work on. Here's what I've gotten done in an afternoon of fiddling with the included documentation and poking through the example source code (after the jump). Already it's a hundred times faster and cleaner than the vertical-shooter engine I wrote for Flash MX back in high school, and I've hardly done anything yet!

I always tend towards shoot-em-up games when experimenting with a new game engine. There's a couple reasons for that. First of all, I love shoot-em-ups. I never get tired of them. Now that Cave is finally porting their games to iPhone (and therefor to my iPad) I'm in bullet-curtained heaven. Secondly, shooters are pretty simple to implement. Enemy behaviors rarely stray outside fixed flight paths, bullets appear in clearly demarcated patterns, and there are no physics to speak of. Finally, I've written engines for these 2d games in several versions of Flash, javascript, and even a 3d engine or two.

Flixel is making it particularly easy to slide back into ActionScript and get some simple game mechanics up and running, though. Too many game engines try to remove coding from the process of game development; Flixel, by contrast, makes coding easy and sensible. Adam's extensions to Flash's Sprite class for FlxSprite make a lot of sense for on-screen game objects, and using a state manager to handle the game loop is so simple it had to be designed.

What I'd like to do next is see Game Programming Patterns expanded to handle some basic event loop / screen object hierarchies.

FlixelProjects.swf Download this file

Rant on: “It doesn’t work” is a meaningless phrase, like “military intelligence” or “world-class synergy.” As a developer, it tells me absolutely nothing. It gives me nowhere to start. It means I have to try and reproduce an error, but I don’t even know what the error is supposed to be.

Instead, tell me what you think should happen, and what’s happening instead. If you get an error message, say, “I’m getting this error message when I go here / click on this link / do this thing…” If something is taking forever, or never loading, tell me that.

In fact, proper bug reports include an expected behavior, an actual behavior, and steps to reproduce that state, as well as any related information (your account name, the project name, url, etc.) Sometimes these bug reports are time-consuming to fill out. But having a developer spend four hours on a tangent fixing the wrong error is generally more costly than collecting all the necessary information in the first place. /rant

I’ve been working extensively with closures in Ruby for the last few months – they are a necessity if you want to keep your code DRY. We were just getting into closures in PHP using the Kohana framework when we began the move to Rails 3, so we got to see first-hand some of the important differences between the two.

The most glaring difference is in the implementation. In PHP, closures are not first-class functions. They are an instance of the class Closure, with a dynamically defined method __invoke(*args). In Ruby, closures are blocks which are converted into instances of class Proc. Procs are first-class functions in Ruby, so there is no overhead in maintaining closures vs. maintaining strictly defined functions. Also, Proc has a lot of useful methods to it, whereas Closure is basically hidden as an implementation detail.

A result of the difference in implementation is that closed variables have to be defined explicitly in PHP via the use() syntax. This is pretty ugly compared to Ruby, wherein closed variables are handled transparently. Syntactically, the PHP version is uglier; writing your variable names in more places means more lines you have to change if that variable ever contains something unexpected. Also, generally closures are short functions; many closures in ruby can be defined in one line using the {|args| … } syntax. Having to explicitly list all the closed variables can extend even a short block’s definition beyond a one-liner.

There is at least one similarity in that both languages have “early-binding” closures. That is, variables are bound at the time the closure is created, rather than when it is called. This makes closures ideal for callbacks such as iterators and templates, since code can be generated with fixed variables bound to the closure, and more dynamic variables passed as arguments.

All in all, I like working with closures in Ruby much more than in PHP; they feel much cleaner and less hacky. But it’s nice to see the PHP team recognize the usefulness of closures in other languages and frameworks. Hopefully as PHP continues to iterate, we’ll see better versions of closures emerge.

Full explanation here: link

tl;dr – (too linked, didn’t read) when you send someone a link, odds are they aren’t gonna click on it. You should always provide a summary, or notes. For example, in the link above, it goes right back to this page. Did you click it?

While this is likely true when you send a link to a few individuals, it is vastly more true about sending a link to a group of people. Email lists are even more impersonal than email, and the amount of responsibility people feel to take action based on something sent to an email list is microscopic.

It’s just a matter of recognizing the limits of people’s attention and trying to conform to them, much like “Don’t make me think”.

I was having an interesting discussion about a few of these terms, and I got a little confused over the exact semantics on these. So here’s my quickie summary.

Blocks: Wiki) A group of declarations and statements meant to encapsulate variables into a scope. Does not necessarily return or expect arguments.

Closures: Wiki) A first-class function whose variables are contained within a scope. Usually created as an anonymous function object.

Matz on Blocks

Procs in Ruby: Behave very much like blocks – they do not check argument counts, for example. Also calling a Proc with a return statement returns from the caller’s scope, since a proc executes in the same scope as the caller.

Lambdas in Ruby: Behave more like named methods. Checks argument counts, and returns values from the contained block when called, not from the caller scope.

Quick example stolen from Wikipedia):

def foo
  f = Proc.new { return "return from foo from inside proc" }
  f.call # control leaves foo here
  return "return from foo"
end

def bar
  f = lambda { return "return from lambda" }
  f.call # control does not leave bar here
  return "return from bar"
end

puts foo # prints "return from foo from inside proc"
puts bar # prints "return from bar"

See this StackOverflow for some examples of Procs and Lambdas in ruby.

We’ve been developing a PVC architecture for a little while now, and there were some things we’ve found which are less intuitive or less convenient than using an MVC architecture. For those not familiar, here’s a basic rundown of Model – View – Controller and Proxy – View – Controller .

The tl;dr version is that PVC is the same as MVC, except instead of having real model classes, you have a proxy that contacts an API with all the model logic. This ensures a complete separation of model code and business logic from presentation and controller code. As engineers, we like separation and modularity – so what are some problems with this architecture?

The most obvious is the extra work involved. Now instead of maintaining one application, you are maintaining two applications. You now have to pull two repos every day – one for the presentation layer and one for the api layer – any time you want to add features that affect both presentation and model. For web applications, that covers most important features. This violates loose coupling and adds extra work.

A less obvious issue is the lack of tools to implement this kind of architecture. Abstracting the interactions between application controllers and databases is a largely solved problem. Libraries such as ActiveRecord, Kohana ORM, Mongoid and others exists to provide robust interfaces between your data and your controllers. With APIs, however, assumptions about the nature of the API cannot be coded into a library. Twitter’s API is different from del.icio.us' API is different from Compete’s API; all of which are different from your API. So almost assuredly there are no robust interaction libraries for dealing with your internal API. This means things like auto-generating forms, error checking, batching and combining queries, and assigning relations between elements will have to be coded by you. We’re working on making this easier with libraries like ObjectStruct and HypertextClient but there’s quite a ways to go there.

Another less obvious issue is multiplicity in testing. Since you have to code your own API interactions to some degree, you have to test that code. This raises some additional questions – in testing your API client, do you mock out your API, or risk creating actual objects (which may have naming or other conflicts) on a staging API? If you mock out your API, how do you maintain and update your mocks? Also, when testing your front-end applications, do you use a mocked API or contact a staging API? Or do you set up more infrastructure to provide clean test databases for each application’s API layer?

In summary, if you’re going to build a PVC architecture, you’re going to be doing a lot of work to make sure all the components fit together in a way that’s tested and secure. This could be worth it – if you have many, many frontend applications, or if you want to allow direct access to an API for third-party clients, having robust individual layers may be to your organization’s advantage. Otherwise, think carefully about whether this is a good approach.

I didn't realize "one and done" was an option. What does that entail?
Try founding a company, and if it fails go running back to the skirts
of a multi-billion dollar corporation? If that's the case, I'm
decidedly on the start-up career path.

The things I like about startups are not replicable at large
companies. The lack of bureaucracy, the ability to talk to anyone
without introduction, the flexibility to experiment, the fast pace and
the ability to use beta and cutting-edge technology are very difficult
to implement at large companies. Because of these things, I've found I
really enjoy working at small companies, and how many people can
honestly say they enjoy what they do? It's something I wouldn't give
up for all the money in the world. No amount of money can buy enough
happiness to make up for eight hours a day of misery.

The terms “casual games” and “hardcore games” appeared to define the differences between tiny, cheap, simple games for platforms like the iPhone, Facebook, or DS and huge, multi-year projects like Fallout 3 or Halo. Casual games have a longer history than most people account for, going back to Flash game portals like Newgrounds and Orisinal or text-based games like Nation States. “Hardcore” games also started from simpler, repetitive games like Galaga and Pac Man, and have grown in complexity with the people who play them.

There are a wide range of attitudes on casual gaming. I got to listen to the CEO of a casual game startup describe the existing console market as ‘absurd’ and ‘ridiculous’ compared to gaming on Facebook. I’ve heard game critics and developers say some pretty nasty things about casual games. I’ve been on both sides of the argument. I’ve pointed out, for example, that even simple games are still games. Getting people to play games is good, because it will lead to more people playing hardcore games. I’ve also mused that casual games are not games because they do not generally rely on learning a set of skills to overcome challenges, but merely putting in time.

Games on Facebook and the iPhone have been heavily constrained by processing power and memory. But that is improving rapidly – Flash is getting GPU rendering, the iPhone and its competitors have more than doubled in power, and these constraints are fading. We’ve seen some “hardcore” games on casual platforms – from the browser-based Quake Live to ports of Monkey Island or Final Fantasy to Flash and the iPhone. We’ve also seen more casual games on traditional platforms – Kinect is making its debut on 360 with Kinectimals, and games like Flower on the PS3 take simple controls and make them wonderful. Steam has a bevy of casual games like Plants vs. Zombies for PC Gamers.

I think going forward, rather than having a sharp divide between ‘casual’ and ‘hardcore’ games, we’ll see it as a continuum of complexity. We’ll see things like ‘casual open-world rpgs’ or ‘casual survival horror,’ and we’ll start to lose sight of where the boundaries are. Minecraft, for example, has simple mechanics that have spiraled into wonderfully creative art projects from its players. I think within a few years, talking about casual games vs hardcore games will be irrelevant, and gamers will have separated into even smaller, more specialized cliques.

We recently switched from Mysql to MongoDB, and it’s been a real learning experience. We’re using Mongoid as our object-document mapper, and we’re finding quite a few gotchas from assumptions we made dealing with Mysql. Here’s an interesting one.

Say you have a controller action like this:

    def add_part
      @car = Car.find(params[:car_id])
      @part = @car.parts.create!(params[:part])
      respond_with @part
    end

@part will save, provided it passes validation. @car may not, though. Say you updated the validation rules on the model, but some of the Car documents still have invalid values on them — @car will not save if those fields are invalid. Worse, it will fail silently, so @part will exist and be valid in your controller code, and @car will be accessible through it. Only if you call @car.reload will all that controller work disappear.

So, if your associations (relational or embedded) are disappearing mysteriously, popping open the rails console and checking for this situation with your models and making sure to call parent.reload is a good place to start.